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Description 

FIELD OF THE INVENTION 

5 [0001] The present invention relates generally to communication systems and, more particularly, to portable wireless 
communication systems. 

BACKGROUND OF THE INVENTION 

io [0002] As is known in the art, wireless Internet access is different from simply accessing the Internet wirelessly. 
Mobile wireless users have different needs, motivations and capabilities from typical wireline users. For example, a 
mobile user is usually in a multi-tasking mode, e.g., accessing the Internet while attending a meeting or shopping in 
the mall. Typical Internet accesses are bursty in nature (checking stock quotes, weather, or finding a nearby restaurant) 
and task-oriented. Thus, browser-centric applications and elaborate user interfaces are of limited utility since a mobile 

15 user usually carries small devices such as a cell phone or a Personal Digital Assistant (PDA) having relatively small 
displays. These personalized devices, which are typically identified by a wireless network address such as a cellular 
phone number, provide mobile users with continuous access to the Internet. 

[0003] Advances in wireless networking and messaging technologies have given mobile users many choices to 
access Internet contents and services. Existing devices and protocots include PDAs, such as Palm Pilots with Web 
20 Clipping, cell phones with wireless application protocol (WAP) or short message service (SMS), email devices, such 
as Blackberry and AT&T PocketNet, supporting Post Office Protocol 3 (POP3) and/or (Internet Message Access Pro- 
tocol) IMAP, and America On Line (AOL) Instant Messaging (AIM). 

[0004] While such devices and protocols can provide limited Internet access, differing devices and protocols do not 
communicate with each other easily. Thus, business and individual mobile users must make challenging decisions to 
25 obtain mobile access in a constantly changing environment. For example, employees of a particular company may 
need to use a single type of device to enable wireless communication between the employees. However, one device 
type may not be optimal or desirable for the duties each employee must perform. 

[0005] It would, therefore, be desirable to provide wireless communication for a variety of mobile device types and 
protocols. It would further be desirable to provide wireless communication with a variety of information spaces. It would 
30 also be desirable to readily support wireless communication for new devices and protocols. 

SUMMARY OF THE INVENTION 

[0006] The present invention provides a mobile device server for providing communication with a variety of protocols 
35 and devices. The mobile device server provides a message gateway for allowing mobile devices using a range of 
protocols and access networks to relay messages to each other and to obtain information from a range of information 
spaces. With this arrangement, a mobile user can readily communicate with other mobile users having the same or 
different devices. A mobile user can also obtain data from a wide range of resources, such as the Internet and data- 
bases. While the invention is primarily shown and described in conjunction with portable mobile devices, it is understood 
40 that the invention is generally applicable to systems in which it would be desirable for differing device types and protocols 
to communicate with each other. 

[0007] In one aspect of the invention, a mobile device server includes a plurality of components that cooperate to 
enable a mobile device to communicate with other mobile device types and with a variety of information space types. 
In one embodiment, a mobile device server includes an engine component that communicates with the mobile server 

4 5 components and maintains user profile information. The server includes a plurality of interface components each of 
which corresponds to a particular device type or protocol, for example. A plurality of access components provide ab- 
stract views of respective information spaces, such as websites, databases, and corporate information. Each of a 
plurality of logic components processes information retrieved by one or more of the access components for transmission 
back to the requesting mobile device via the corresponding interface component. 

50 [0008] The engine component communicates with the interface, access and logic components and maintains user/ 
device profiles. In one embodiment, the engine component communicates with the interface components in a prede- 
termined format, translates aliased user commands, invokes appropriate logic and access components, and transcodes 
retrieved data into a format based upon characteristics, e.g., display size, of the requesting device. 
[0009] In an exemplary operation, a mobile device issues a request for the latest stock price of a particular company. 

55 The mobile device has a particular messaging client, such as America On Line's Instant Messenger (AIM). The mobile 
device communicates with the mobile device server via an AIM interface component, which receives the request for 
stock data and formats the request into a predetermined format. The engine component receives the formatted request, 
validates the mobile user identification, and transforms command aliases, e.g., q for "quote". 
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[0010] The engine component then sends the data request to an appropriate logic component, which can for example, 
determine an optimum stock quote service based upon certain criteria. The logic component then requests the engine 
component to invoke the appropriate access component corresponding to the selected quote service, e.g., Yahoo. The 
access component then utilizes the proper mechanism, e.g., Hyper Text Transfer Protocol (HTTP), to retrieve the 
5 requested content. 

[0011] The retrieved raw content is returned to the engine component for examination and formatting. The engine 
component accesses the profile of the recipient device to which the requested information is to be sent, which may or 
may not be the requesting mobile device. Based upon the profile of the recipient device, the engine component invokes 
an appropriate access component for transcoding the retrieved raw content into the appropriate format, e.g., text only. 
10 The engine component then delivers the transcoded data to the interface component corresponding to the recipient 
device for transmission. 

BRIEF DESCRIPTION OF THE DRAWINGS 

15 [0012] The invention will be more fully understood from the following detailed description taken in conjunction with 
the accompanying drawings, in which: 

FIG. 1 is a schematic depiction of a mobile device server for communicating with a variety of devices and networks 
in accordance with the present invention; 
20 FIG. 2 is a schematic block diagram of an exemplary architecture for the mobile device server of FIG. 1 ; 

FIG. 3 is a schematic block diagram showing the mobile device server having a plurality of interface devlets in 
accordance with the present invention; 

FIG. 4 is a schematic depiction of an exemplary communication path configuration for a mobile device server in 
accordance with the present invention; 
25 FIG. 5 is a schematic block diagram showing the mobile device server having a plurality of access infolets in 

accordance with the present invention; 

FIG. 6 is a schematic block diagram showing a first part of a data transfer by a mobile device server in accordance 
with the present invention; 

FIG. 7 is a schematic block diagram showing a second part of a data transfer by a mobile device server in accord- 
30 ance with the present invention; 

FIG. 8 is a schematic block diagram showing a third part of a data transfer by a mobile device server in accordance 
with the present invention; 

FIG. 9 is a schematic block diagram showing a fourth part of a data transfer by a mobile device server in accordance 
with the present invention; 

35 FIG. 10A is an exemplary screen display showing Internet access of flight info from an AIM device through the 

AIM devlet on the mobile device server in accordance with the present invention; 

FIG. 10B is an exemplary screen display showing website news access from a Palm V device through the email 
devlet on the mobile server in accordance with the present invention; 

FIG. 11 A is an exemplary screen display for a device accessing a corporate database through the JDBC infolet 
40 on the mobile device server in accordance with the present invention; 

FIG. 11 B is an exemplary screen display for a mobile phone accessing a corporate database through the JDBC 
infolet on the mobile device server in accordance with the present invention; 

FIG. 12 shows an exemplary screen display for a device requesting service from a CORBA object through the AIM 
devlet on the mobile device server in accordance with the present invention; 
« FIG. 13 is an exemplary screen display for a device controlling X1 0 home network devices through the AIM devlet 

on the mobile device server in accordance with the present invention; 

FIG. 14 is an exemplary screen display for a device accessing an inbox of an E-mail account through the AIM 
devlet on the mobile device server in accordance with the present invention; 

FIG. 15 is a pictorial representation of an applet for finding a movie for a mobile user of a mobile device server in 
so accordance with the present invention; and 

FIG. 1 6 is a schematic representation of an instant messaging mechanism for a mobile device server in accordance 
with the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

55 

[0013] In general, the present invention provides a mobile device server that operates as a message gateway for 
allowing mobile devices using various protocols on different access networks to communicate with each other. The 
mobile device server also allows mobile clients to access resources and information on the Internet and various other 
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networks. The mobile device server includes a flexible architecture having a plurality of components that cooperate to 
service mobile device communication requests. Mobile device server components include a let engine component 
communicating with interface devlets, logic applets, and access infolets. This arrangement allows the mobile device 
server to readily support new devices and protocols by adding corresponding devlets, infolets, and applets without 

5 altering the existing service logic. 

[0014] As described more fully below, interface devlets receive and send messages through a particular protocol 
used by various mobile devices. Access infolets utilize particular access methods to provide an abstract view of re- 
spective information spaces. And access applets implement service or application logic by processing information from 
one or more infolets. The let engine provides the basic framework for maintaining applets, devlets and infolets, sup- 

10 porting user and device profiles for personalization and transcoding, and invoking proper applets and infolets to answer 
data requests from devlets. 

[0015J FIG. 1 shows an exemplary embodiment of a mobile device server 1 00 for enabling mobile users to commu- 
nicate with a variety of devices and protocols in accordance with the present invention. The mobile device server 100 
can run on a computer 1 02 having connections to a plurality of networks and devices. It is understood that the mobile 
15 device server can operate on a variety of known computers and operating systems, such as Unix and Windows. In 
one embodiment, the mobile device server 100 is implemented using the Java programming language running in a 
Windows environment. 

[0016] The mobile device server 1 00 further includes a mobile phone device 1 04 for receiving and transmitting data 
via wireless communication. The mobile phone 1 04 can support Short Message Service (SMS) communication, which 
20 js well known to those skilled in the art. While shown as a wireless phone coupled to the computer, it will be readily 
apparent to one of ordinary skill in the art that mobile device server functionality can be readily integrated into a single 
device. In addition, the mobile device server can include a number of wireless devices, which can be the same or 
different type, coupled to the computer 102. 

[0017] The mobile device server 100 enables communication between various devices and networks. In the illustrated 
25 embodiment, a cell phone 200 with two-way short messaging service (SMS), e.g., a Global System for Mobile Com- 
munication/Time Division Multiple Access (GSM/TDMA) phone connected to a GSM/TDMA network 202, can com- 
municate with the mobile device server 1 00 through an SMS driver hosted on the mobile device server. Cellular Digital 
Packet Data (CDPD) devices 204, such as AT&T PocketNet phone 204a and Palm V 204b, coupled to a CDPD network 
206 can use a Wireless Access Protocol (WAP) gateway 208 to access the mobile device server 100 through the 
30 Internet 210. Email devices 214, such as a Blackberry mobile device, can use the Standard Email Protocol (SMTP) 
on the CDPD network 206 or a two-way paging network 216 coupled to a mail server 218 to communicate with the 
mobile device server 100. 

[0018] In addition, PC device users and some PDAs can use AOL Instant Messenger (AIM) or web browsers to 
communicate with the mobile device server 100, which can support a Transmission Control Protocol (TCP) interface. 
35 Mobile devices can include an embedded module for communicating with the mobile device server 100 directly via the 
TCP interface. The mobile device server 1 00 can receive messages and commands from these devices, access Internet 
services and information on behalf of a mobile user, and relay messages or Internet content back to the sending devices 
or other devices, as described more fully below. 

[0019] The mobile device server 100 includes an architecture having a plurality of interface, logic, and access com- 

40 ponents that enable the mobile device server to communicate with a range of devices, protocols and information spaces. 
This arrangement hides the complexity of multiple devices and content sources from mobile users. The mobile device 
server 100 can include a proxy server that provides an environment for hosting agents and personalized services, 
which can be implemented as reusable building blocks in the Java programming language, for example. An exemplary 
proxy server known as iProxy, is shown and described in U.S. Patent Application Nos. 08/974,600, filed on December 

45 19, 1997, and 09/474,914, filed on December 30, 1999, which are incorporated herein by reference. In general, an 
iProxy agent, which can include a web-server, can be invoked like a regular common gateway interface (CGI) program. 
The iProxy system also allows scripts embedded inside web pages to invoke agents to perform specialized processing. 
The iProxy system maintains user profiles and adds intelligence to the traditional HTTP proxy server to provide per- 
sonalized, and value-added services such as filtering, tracking, and archiving. 

so [0020] FIG. 2 shows an exemplary architecture for a mobile device server 300 having a plurality of components that 
combine to provide a flexible architecture that can readily support new devices, interfaces and information spaces. In 
one particular embodiment, the mobile device server 300 includes interface devlets 302, logic applets 304 and access 
infolets 306. The devlet, infolet, and applets 302, 304, 306, as well as a proxy interface 308, communicate with each 
other through a let engine 310. These components can be implemented as iProxy agents. 

55 [0021] As shown in FIG. 3, each interface devlet 302 provides a protocol interface to a given device on a particular 
access network. As described above, exemplary access network types include the Internet, CDPD, and GSM/TDMA, 
each of which is supported by one or more corresponding interface devlets. In the illustrative embodiment, an AIM 
devlet 302a, a GSM/TDMA devlet 302b, a TCP/IP devlet 302c, and a SMTP/IMAP devlet 302d are shown for commu- 
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nicating with the corresponding networks. It is understood that further interface devlets can be provided for a variety 
of additional protocols well known to one skilled in the art. For example, email devlets can include SMTP, IMAP and 
POP3 devlets for sending and retrieving email. 

[0022] The interface devlets 302 interact with the let engine 310 via a predetermined interface format. In one particular 
5 embodiment, the devlets 302 provide requests to the let engine 310 in character-stream command lines and the let 

engine returns results in Multipurpose Internet Mail Extensions (MIME) format. After the mobile device server 300 is 

initialized, each interface devlet 302 monitors a respective channel for incoming requests sent by a remote mobile 

device. For example, the AIM devlet 302a on the mobile device server starts an AIM client for listening to service 

requests from other AIM clients sent as instant messages. 
w [0023] It is understood that the required device driver can form a part of a corresponding interface devlet 302 or can 

communicate with the devlet through a TCP protocol, for example. This approach allows a device driver to run on a 

remote machine, i.e., a device other than on the mobile device server. 

[0024] FIG. 4 shows an exemplary communication path between an SMS mobile station MS and a mobile device 
server MDS in accordance with the present invention. An SMS devlet running on the mobile device server MDS corn- 
's municates with a GSM cell phone MS attached to a remote personal computer RPC through an SMS driver. Mobile 
users can send messages to the cell phone MS (through the GSM network), which then forwards each message to 
the mobile device server MDS for processing. The mobile device server MDS then returns the result to the mobile user 
through the same channel. Such an Arrangement is further shown and described in U.S. Provisional Patent Application 
No. 60/206167 entitled "Mobile Phone Internet Access Utilizing Short Messages Services," filed May 22, 2000, which 
20 is incorporated by reference herein. 

[0025] Similarly, to allow access to the mobile device server through email, a mobile device server email devlet can 
monitor messages arriving at a particular email account for new service requests. For TCP users, a TCP session is 
created upon receiving a request to connect with a particular port of the mobile device server machine using the telnet 
protocol. The telnet user can enter mobile device server commands as if using a typical Unix or Windows terminal for 
25 example. The mobile device server can also support the WAP and HTTP protocols through the proxy interface 308 
(FIG. 2). 

[0026] Referring again to FIG. 2, while each protocol and device can have unique interfaces, each corresponding 
interface devlet 302 interacts with the let engine 310 in a predetermined format. More particularly, a devlet 302 can 
send a data request in the form of a character stream, interpreted as an mobile device server command and associated 
30 parameters, to the let engine 31 0. The devlet 302 can receive results from the let engine 31 0 in a Multipurpose Internet 
Mail Extensions (MIME) format appropriate for the device, which is determined by the corresponding device profile 
stored at the let engine. Device profiles contain information for user devices, such as how much information can be 
displayed. 

[0027] A simplified version of the mobile device server command syntax is listed below: 

35 



<command> := [ <forward_command> <destinations> ] 
40 <applet_command> [ <appleLargument> ]* 

<destinations> := <destination> [ V <destination> ]* 
<destination> := <protocol> ":" <account_jd> 

45 

In this particular embodiment, the naming of each device or destination follows the conventional URL naming scheme: 
protocol name followed by an account name or address. For example, typical destination addresses include "sms: 
+1 9735556242" (GSM cell phone), "aim:sunshineX" (AIM buddy name), "mail:iproxy@ research.att.com (email id)", etc. 
[0028] As described more fully below, after receiving the command, the let engine 310 invokes one or more logic 
so applets 304 that implement the required logic for the data request. The let engine 310 then invokes the access infolet 
306 appropriate for the information space to be accessed. 

[0029] Referring briefly to FIG. 5, the access infolets 306 extend beyond the HTTP protocol and URL name space 
to provide abstract views of various information spaces, such as databases 350, Internet information sources 352, 
core networks 354, and X10 home devices. Corresponding access infolets, such as Java Data Base Connectivity 
55 (JDBC) 306a, http 320b, CORBA 306c infolets access the respective information spaces as shown. A given interface 
infolet 306 retrieves information from a particular information space, such as stock quote sites, weather sites, and 
airline flight databases. It is understood that the same information may be accessed using a variety of access protocols. 
For example, such information is commonly available on many websites, and may also be retrieved from XML files or 
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databases. An interface infolet retrieves the original content and returns it to an appropriate applet 304 for further 
processing, as described more fully below. 

[0030] As an example of a mobile station request to access the stock price of AT&T (stock symbol T), the mobile 
device user can issue a "quote T" command. If the request is sent by a mobile user using SMS on the GSM network, 
5 then the result will be returned as plain text to the requesting GSM cell phone. If the mobile user wants to forward the 
result to an email address, e.g., herman@research.att.com, the user issues a "forward mail :herman@ research. att. 
com quote T" command. Since that email account understands the MIME type text/HTML (according to the device 
profile), the result will be sent by the let engine as an HTML file, complete with graphics, to the herman @ research. att. 
com email account. 

w [0031] The interface devlets 302 allow users on different networks to readily communicate with each other. For ex- 
ample, if a GSM phone user wants to send a message to other devices, such as an AT&T PocketNet mail account, e. 
g. : chen@mobile.att.net, which is on the CDPD network, and an AT&T TDMA phone having phone number 
555-500-6531 using SMS, then an echo applet can use a message relay service as follows: "forward mail:chen@mo- 
bile.att.net, attmsg:5555006531 echo call your boss." 

15 [0032] FIGs. 6-9 show an exemplary transaction between a mobile device MS and a mobile device server 300 in 
accordance with the present invention. As shown in FIG. 6, the mobile device MS, such as a Palm Vx with a CDPD 
modem having an AIM client, issues a "q T" (quote AT&T -stock symbol T) command, which requests that the mobile 
device server 300 retrieve the current price of AT&T stock. The Palm Vx MS establishes a communication channel 
with the mobile device server 300 via an AIM devlet 302a, e.g., imobile4att. The AIM devlet 302a receives the instant 

20 message from the Palm Vx device and formats the message into a predetermined format, e.g., "q T" in text, prior to 
passing the message to the engine component or let engine 310. The engine component 310 transforms any aliases, 
e.g., q for quote, defined by the mobile device user and authenticates the user. The engine component 31 0 then invokes 
the appropriate logic applet 304b, which can implement predetermined logic for selecting a stock quote service, such 
as MSN, Yahoo : Etrade, etc. 

25 [0033] As shown in FIG. 7, the logic applet 304b then requests the let engine 310 to invoke the appropriate, e.g., 
http, access infolet 306a. In FIG. 8, the access infolet 306a retrieves the request stock information using the mechanism, 
e.g. , http, appropriate for the selected quote service. The infolet 306a then returns the raw data, which can be in HTML 
format, to the let engine 310. 

[0034] As shown in FIG. 9, the let engine 310 examines the raw data, as well as profile data for the recipient device, 
30 which can be the same or different from the requesting mobile device MS.. For example, the mobile device MS can 
request data to be forwarded to a specified device, such as an email account. Based upon the profile of the recipient 
device, the let engine 310 can send the raw data to a transcoding infolet 306b for processing. In the case where the 
recipient device accepts only text in messages less than 1000 bytes, the transcoding infolet 306b transcodes the raw 
data accordingly. After the infolet converts the data into text, the let engine 310 then delivers the text message to the 
35 AIM devlet 302a, if the Palm Vx device MS is the recipient device. 

[0035] It is understood that the mobile device server of the present invention can communicate with a wide variety 
of mobile device types. In addition, the architecture of the mobile device server can readily support new functionality 
with applets, new devices with devlets, and new information spaces with infolets. 

[0036] FIG. 1 0A shows an AIM client, mingfengchen, on an exemplary mobile device that talks to the mobile device 
40 server AIM agent, mfchen4iproxy. The AIM client issues the "flight 001 " command to get flight information on a particular 
airline and receives output including time and gate information for each leg of the flight. Mapping from the flight com- 
mand to the airline can be controlled by a corresponding logic applet according to the user profile. Also, the let engine 
invokes necessary transcoding services to map the elaborate content on the airline website to the receiving device 
according to AIM device's profile. 
45 [0037] FIG. 10B shows a Palm V device having an Omnisky modem that just sent an email to the mobile device 
server email devlet at imobile@research.att.com with the command "sitenews att." This command instructs the mobile 
device serverto access the service provided by AT&T's Website News, which reports new hyperlinks on AT&T's website 
(http://www.att.com). The result is sent back as an email formatted for the Palm V device. 

[0038] FIG. 11 A shows a mobile user connecting to an enterprise database through an AIM client to find contact 
so numbers for a particular software application using the mobile device server of the present invention. FIG. 1 1 B shows 
how to access the same information from a cell phone that supports the WAP protocol. Corporate Information is typically 
accessed through JDBC and ODBC interfaces. The mobile device server includes a JDBC infolet that allows mobile 
users to access enterprise database information (marketing/sales data, system interface, etc.) through SQL-like que- 
ries. 

55 [0039] Network/Infrastructure Resources are typically accessed through the CORBA (Common Object Request Bro- 
ker Architecture) interface. As known to one of ordinary skill in the art, CORBA is an architecture and specification for 
managing distributed program objects in a network to allow programs at different locations to communicate through 
an "interface broker." The mobile device server hosts a CORBA infolet that allows mobile users to request services 
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from CORBA objects. FIG. 12 shows how an AIM user gets phone diversion information for the user Herman. 
[0040] FIG. 13 shows a mobile device user controlling X10 devices remotely via the mobile device server of the 
present invention. The X10 home network technology allows lamps and appliances connected on the same power line 
to be controlled by a computer. The mobile device server hosts an X10 infotet that controls home network devices 

5 connected to its server machine. First, the user instructs the mobile device server to locate the firecraker, the device 
that is capable of sending a radio signal to a transceiver device on the X10 network, through the serial port COM2 on 
the mobile device server host. After the connection is established, a command, e.g., "x10 on a1" is sent to turn on the 
fan (which is named device a1 on that particular X10 network) and "x10 on a2" to turn on the coffee pot. The X10 
interface allows a mobile user to control the lighting and appliances at home with a GSM cell phone, an AIM client, or 

io an email device anywhere in the world. The X10 infolet also demonstrates that an infolet can be used to both retrieve 
and change the state of an information space. An applet based on X10 infolets can use an algorithm to determine 
when and how to activate certain X10 infolets to control a home environment. 

[0041] Further application for utilizing the mobile device server to access home network devices will be readily ap- 
parent to one of ordinary skill in the art. For example, motion sensors can be activated and de-activated using a mobile 

'5 device, such as a cell phone. A user can instruct a recording device to tape a television program using the mobile 
device server. It is understood that a variety of devices can be used to access a home network. That is, a user can 
utilize any of a ceil phone, PC, PDA, Palm device, etc. to manipulate home network devices. It is further understood 
that while the mobile device server is primarily described as supporting mobile devices, non-mobile devices such as 
desktop PCs can communicate with the mobile device server. 

20 [0042] FIG. 14 shows a mobile user accessing an email account via a mobile device server in accordance with the 
present invention. The mobile user first checks the status of the inbox to find the number of unread messages. The 
mobile device server supports an IM AP infolet called inbox that can query and view a user's email account. The mobile 
user can look at the size, e.g. , 728 bytes, subject, and sender of that message before actually viewing it. Such interaction 
is advantageous for a mobile user with limited bandwidth and screen space on a mobile device. 

25 [0043] As described above, an applet implements business, service, or application logic by processing contents from 
different sources and relaying results to various destination devices. A simple applet is the "echo" applet described 
above, which sends a message from one device to another without using any information sources. It is understood 
that an applet can also have relatively complex interactions with other infolets. 

[0044] As showin in FIG. 15, for example, a FindMeAMovie applet can be implemented as an iProxy script as shown 
30 below. 

#!/iproxy/script 

35 # get the localtion information (zip) 

:javabin infoLet zip getlocation 

# get top 10 movies (mlist) 
40 rjavabin infoLet mlist top 1 0 movie 

:foreach mtitle ${mlist} 

45 



50 



55 
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# Find theaters 



5 



- Movie: ${mtitle) 

:javabin infoLet thlist findTheater ${mtitle) ${zip} 
iforeach theater ${ thlist} 



10 



# List the title & theater 



${theater} 



xndfor 



15 



rendfor 



This applet finds theaters near a cell phone user that are currently showing the top ten movies by executing the following 
steps: 1) find out the location (zip code) of the cell phone user, 2) find the top 10 movies from a movie database or 
20 website, 3) for each of these movies, find out if any local theater shows that movie, and 4) list the move title and the 
theater. 

[0045] In general, each devlet, infolet, and applet must be registered at the let engine first before communications 
with other agents can occur. Each abstract device that communicates with the mobile device server must register its 
profile information with the let engine first. A device name is designated by protocol and account ID 5 i.e., protocol: 

25 acct_id. For example, an AIM userwebciao is named aim:webciao. The mobile device server maintains a default profile 
for each device type, and each instance of a device can overwrite that profile with device-specific information. A device 
profile can simply be a list of attribute-value pairs. An important attribute is dev.format. accept, which determines what 
MIME type the device is allowed to accept. This information is used by the mobile device server to transcode original 
content to a format appropriate for this device, as described above. For example, the default profile for an email device 

30 js the following and can be named mail.ini in the directory in which device profiles are kept: 



40 The above device profile indicates that the default MIME type is text/html, but all MIME types(7*) are acceptable. Also, 
the page size "-1 " indicates that there is no limit on the size of each message transmission. These values are inherited 
by all mail devices unless they are overwritten. For example, while the two default values might be valid for primary 
email devices (desktop or laptop PC's), they are not appropriate for emails used on cell phones, such as AT&T's 
PocketNet phone. The following device profile for a PocketNet phone indicates that only the MIME type text/plain is 

45 appropriate for this device and that it does not accept messages longer than 230 characters: 



[0046] A devlet can require additional information that tells the mobile device server how and when to access this 
device. For example, the following profile for the address imobile@research.att.com, used by the email devlet of the 
mobile device server, specifies the frequency (every 1 0 seconds) of checking the email account (store. checktime), the 
account password (store. url), the transport protocol for sending email (transport. url), last time the user accessed the 
55 account (cmd.lasttime), etc. 



35 



dev.format.accept=text/html,*/* 
dev.page.size=-l 



dev.format.accept=text/plain dev.page.size=230 



50 
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mail.store.checktime=10000 

mail.stGre.url=imap://imobile:password@bigmail 

maa.transport.url=:smtp://bigmail 

[0047] In general, each device Is mapped to a registered user of the mobile device server. Significant reasons for 
this mapping arrangement include limiting access to legitimate users of the mobile device server; and personalizing a 
service based on the user profile. An illustrative device-to-user map stored in the server (rarp.ini) is set forth below: 

sms:+88693555 1 826=herman 
sms:+l 9085556842=chen 
mail:dchang@rcscarch.att.com=difa 

aim:webciao=chen ... 

[0048] It is understood that the mobile device server of the present invention can rely upon a variety of authentication 
techniques. Since the mobile device server interacts with multiple networks and protocols, the server relies on different 
authentication mechanisms. In one embodiment, the mobile device server uses the cell phone identification on wireless 
phone networks, AOL buddy names on the AIM network, and generic user ID and password information for WAP, 
HTTP, and telnet clients. However, the mobile device server itself does not have control over the security afforded by 
some of these networks. Alternative embodiments can include the SSH Secure Shell to provide end-to-end authenti- 
cation services. In general, the technique used by the mobile device server to authenticate a mobile user depends on 
the device or protocol used. Trusting wireless networks, such as Voicestream/GSM and AT&T TDM A networks, to 
provide the correct cell phone id when a short message (SMS) is received is generally acceptable unless a cell phone 
is stolen and the user did not lock the phone with a security password. The mobile device server can also trust the 
AOL network authentication for non-critical services. User authentication through the mobile device server itself is 
required if the user accesses the mobile device server through telnet, WAP, or HTTP. Following is a typical and simple 
user profile: 

name=Robin Chen 
password=xf2gbH3 
default=$mail.l 

# my addresses 

sms. 1 =sms:+ 1 9085556842 

mail. l=mail:chen@research.att.com 

mail.2=mail:imobile@mobile.att.net 

mail.all=$mail. 1 ,$mail .2 

aim.l=aim:webciao 

# command aliases 
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smsxmd.q=quote 
sms.cmclsn=sitenews 
# address aliases 
sms.addr,cc=aim:chrischen 

10 This user profile stores the user name, password, and a list of the devices that the user registers with the mobile device 
server. It also stores command and address aliases. When a user accesses the mobile device server through AIM 
using the id webciao, the mobile device server determines from the user-device map that the user is chen and uses 
the user profile chen.ini for all later service requests from this device. For example, the following short message sent 
from a GSM phone: "forward $mail.1 q T" is interpreted as 'forward mail:chen@ research.att.com quote T" according 

15 to the user profile. The special character "$" requests that the mobile device server map the named device, i.e., mail. 
1 , to its corresponding entry in the profile. 

[0049] In a further embodiment, the mobile device server supports event driven message generation to one or more 
users. In general, a user is considered to have previously requested such information when the predetermined event 
occurs. For example, in the event that a child is absent from school a message is sent to the parents cell phone. The 

20 message can be sent to a plurality of devices associated with the parent to ensure that the message is noticed. In 
addition, messages can be schduled for delivery at predetermined times. For example, a scheduler applet can peri- 
odically check for scheduled events. For example, the mobile device server can send a message to a device at a 
predetermined time to alert a person that a daily medication should be taken. It is understood that a user can be mapped 
to multiple devices in the user profile. For example, a user can add to a daily journal located in a one address location 

25 via multiple devices, such as a cell phone, PDA, and PC. 

[0050] FIG. 1 6 shows an exemplary embodiment of mobile device server components for supporting an instant mes- 
saging mechanism among a plurality of devices. In one embodiment, the instant messaging mechanism includes a 
talkto applet 400, a session ID applet 402, and a talkover applet 404. The talkto applet is invoked by the engine com- 
ponent 406 in response to a users request for instant messaging with another device, which can be of the same or 

30 different type. The engine component then generates the session ID applet 402 for providing a session ID to each 
device participating in the instant messaging. The name of the applet corresponds to the session ID, which is shared 
by the instant messaging users. The talkover applet 404 terminates parties from the instant messaging session. When 
all of the parties have left the session, the session ID applet 402 ceases to exist. 

[0051] One skilled in the art will appreciate further features and advantages of the invention based on the above- 
35 described embodiments. Accordingly, the invention is not to be limited by what has been particularly shown and de- 
scribed, except as indicated by the appended claims. All publications and references cited herein are expressly incor- 
porated herein by reference in their entirety. 

[0052] Where technical features mentioned in any claim are followed by reference signs, those reference signs have 
been included for the sole purpose of increasing the intelligibility of the claims and accordingly, such reference signs 
40 do not have any limiting effect on the scope of each element identified by way of example by such reference signs. 



Claims 

45 1 . A mobile device server system for processing data requests from a variety of mobile device types, comprising: 
an engine component; 

a plurality of interface components communicating with the engine component in a predetermined format, 
each of the plurality of interface components for providing a respective interface for mobile devices sending 
50 data requests; 

a plurality of access components communicating with the engine component, each of the plurality of access 
components for providing an abstract view of a respective information source type based upon the data re- 
quests; and 

a plurality of logic components communicating with the engine component, each of the plurality of logic com- 
55 ponents for processing information retrieved by the plurality of access components and providing the proc- 

essed information to one or more of the plurality of interface components for transmission. 

2. The system according to claim 1 , further including a proxy interface for providing a communication interface to the 
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mobile device server. 

3. The system according to claim 1 , wherein the plurality of interface components includes components for supporting 
protocols selected from the group consisting of supporting interfaces to AIM, ICQ, SMS, XMS, Telnet, HTTP, WAP, 
SMTP, IMAP, POP3, and IVR. 

4. The system according to claim 1 , wherein the plurality of access components includes components for providing 
access to information spaces selected from the group of access components consisting of ODBC, JDBC, CORBA, 
http, X10, email, and XML 

5. The system according to claim 1 , wherein the predetermined format includes text for transfers from the plurality 
of interface components to the engine component. 

6. The system according to claim 5, wherein the predetermined format includes MIME for transfers from the engine 
component to the plurality of interface components. 

7. The system according to claim 1 , wherein the variety of mobile device types include devices selected from the 
group consisting of SMS mobile phones, PDA devices, Instant Messaging devices, Email devices, two way pagers, 
pocket PCs, and AT&T Pocket Net devices. 

8. The system according to claim 1 . wherein the mobile devices can communicate with one or more of CDPD, TDMA, 
GSM : two way paging, Internet, and email networks. 

9. The system according to claim 1 , further including a logic component for redirecting the processed information to 
a further device associated with the first mobile device. 

10. The system according to claim 1 , further including a logic component for scheduling an activation and/or response 
to a data request. 

11 . A method for enabling communication between a variety of mobile device types, comprising: 

receiving a first data request from a first mobile device utilizing a first protocol; 
receiving a second data request from a second mobile device utilizing a second protocol; 
formatting the first and second data requests into a predetermined format; 

processing the first data request to initiate an information exchange between the first mobile device and a first 

information space associated with a first information source; 

retrieving requested data for the first data request from the first information source; 

formatting the retrieved data based upon parameters associated with the first mobile device; and 

sending the formatted data to the first mobile device using the first protocol. 

12. The method according to claim 1 , further including supporting an additional type of mobile device by adding an 
interface component supporting the additional mobile device type. 

13. The method according to claim 11 , further including supporting an additional type of information space by adding 
an access component supporting a protocol for accessing the additional type of information space. 

14. The method according to claim 11, further including supporting an additional service function by adding a logic 
component supporting the additional service. 

15. A method for adding new components to a mobile device server having a flexible architecture, comprising: 

providing an engine component; 

providing a plurality of interface components communicating with the engine component in a predetermined 
format, each of the plurality of interface components for providing a respective interface for mobile devices 
sending data requests; 

providing a plurality of access components communicating with the engine component, each of the plurality 
of access components for providing an abstract view of a respective information source based upon the data 
requests; 
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providing a plurality of logic components communicating with the engine component, each of the plurality of 
logic components for processing information retrieved by the plurality of access components and providing 
the processed information to one or more of the plurality of interface components for transmission to the mobile 
device that sent the data request; and 
s adding a further one of an interface component, access component and a logic component to support a re- 

spective mobile device : information source, and process without altering service logic of the mobile device 
server. 

16. A method for servicing data requests by a plurality of mobile device types, comprising: 

10 

receiving a data request from a first mobile device via a respective one of a plurality of interface devlets; 
formatting the data request to a predetermined format; 
passing the formatted data request to a let engine; 

invoking at least one of a plurality of logic applets based upon the data request; 
15 invoking a respective one of a plurality of access infolets based upon an information space type associated 

with the data request; 

retrieving raw data from a device corresponding to the information space type; 

formatting the raw data based upon characteristics of a recipient device specified in the data request; and 
passing the formatted the data to the recipient device via an interface devlet supporting the recipient device. 

20 

17. The method according to claim 1 6, further including formatting the data request into text. 

18. The method according to claim 1 6, further including formatting the raw data into MIME. 

25 19. The method according to claim 1 6, wherein the characteristics of the recipient device include a size limitation. 

20. The method according to claim 16, further including servicing data requests from devices including at least two 
device types selected from the group consisting of SMS mobile phones, Palm devices, AIM devices, AOL devices, 
two way pagers, pocket PCs, and AT&T Pocket Net devices. 

30 

21. The method according to claim 16, further including supporting an additional type of mobile device by adding a 
corresponding interface devlet without altering service logic. 
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Fig. 4 
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Fig. 6 
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Fig. 8 
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Fig. lOA 
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Fig. lOB 
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iproxy4.att - Instant Message 
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Fig. 12 
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Fig. 13 
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Fig. 14 



mfchen4iproxy - Instant Message 
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Subject: [iproxy] meeting time. 
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mfchen4iproxy: Dear all: 

The meeting time is changed to this afternoon. 
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Fig- 15 
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